@s0me0ne-unkn0wn I thought about that also. If executor params can affect preparation, then it would invalidate the assumptions documented here. Probably we would have to do pre-checking again when changing any parameter that can affect the runtime. Is there already an issue for this?

What executor params could be controlled?

@burdges current list is like that:

• Wasm executor max. memory size
• Wasm stack limit
• Native stack limit
• PVF preparation timeouts: one for pre-check and another for execution
• PVF execution timeouts: one for backing and another for approval voting/dispute participation etc.

Planned but not yet implemented:

• Wasm compiler max. memory size for preparation (#6472)
• Some collator-related limits, not yet discussed in detail (Ensure that collators respect the backers timeout polkadot-sdk#72 and Collator execution environment parametrization #6497)

Probably we would have to do pre-checking again when changing any parameter that can affect the runtime

We can do that, but what's next? We cannon un-enact a PVF. Consider the situation when it's the first and only PVF for a parachain just onboarded.

Is there already an issue for this?

Just created paritytech/polkadot-sdk#694, let's continue there.

I suppose Wasm stack limit is a stack used by Wasm code, while native stack limit is used by the Wasm engine, our host calls, etc., yes? Aside form the two existing and planned preperation limits then these all sound more determined by the block than by the runtime, so not a new problem and not sure why they'd require rebuilding.

As for the two existing and planned preperation limits, are we instrumented to record the current max during preperation? I suppose no as code is rarely instrumented like this, but if so then we could just deactivate the PVF if the recorded limit gets invalidated on chain.

Anyways our problem is a preperation limit change could make preparing an already valid PVF impossible, which gives an adversary some control over who can check the PVF. Importantly, we should not enact a limit change immediately, just like we do not enact a PVF change immediately. Assuming all validators do rebuild, then yeah we'd prepare to unenact the PVF but governance should've time and ability to revert the limit change. Isn't this enough?

We could even have the vote block the limit change, so then governance should manually boot any fat parachains before reducing limits. Is that simpler? It's also kinda shitty that all validators must rebuild just to check a preperation limit violation.

We can do that, but what's next? We cannon un-enact a PVF. Consider the situation when it's the first and only PVF for a parachain just onboarded.

We could (not saying we should) don't accept execution environment parameter updates if pre-checking fails for a PVF that was valid before. So changing parameters would also be pre-checked, by re pre-checking all PVFs before enacting them. I actually think this is absolute overkill and does very likely more harm than good, but in that particular case we "could" do something. Realistically, I think we have to accept a small risk and live with it.

As for the two existing and planned preperation limits, are we instrumented to record the current max during preperation? I suppose no as code is rarely instrumented like this, but if so then we could just deactivate the PVF if the recorded limit gets invalidated on chain.

@burdges Just to answer your question, we do have instrumentation for preparation memory usage and time taken. Agree with the rest of your post.